This invention is often discussed herein in the context of financial risk management, but this invention is much broader in its application because the tree-based database according to this invention may be used for literally any type of heterogeneous data.
Financial risk-management systems rely on complex object models for the storage, query and update of data. Each point of the data is derived from a diverse set of inputs that depend on market data, trade details and configured parameters. The number and type of these inputs differs widely among different categories of risk exposure; however, the risk manager needs to see the data as a single, unified search space for reporting and analysis.
The same applies for any other type of complex system that relies on a wide range of different data structures. As will be discussed in the following sections, conventional database models fail to adequately support such complex systems and fail to provide a unified search space for the query and aggregation of results.
The Relational Database Model
The conventional relational model is often used as the foundation for financial risk management systems. The strength of the relational model is presenting and manipulating tabular collections of data where each column of data has the same structure. However, it does not easily lend itself to representing collections of data with diverse structures.
If a relational database model is adapted to support widely diverse data structures, one of two approaches are typically adopted. In the first approach, the structural aspects of the database are increased in complexity in order to accommodate the diverse data structures. For instance, every distinct structure may be represented with a separate table linked to a primary table with a “key.” Each distinct structure also has its own procedures for query and update. This approach is very inflexible, and in the worst case, the addition of a new structure requires all the procedures to be rewritten.
In the second approach, the relational database is simplified in order to make all data elements fit the same structure. This approach leads to redundancy and expansion of storage requirements in the database. For example, a scalar value (i.e., a zero dimensional point) might have additional, redundant x and y values so that one and two-dimensional points can be stored in the same table. Any new structures that do not fit the database structure either have to be trimmed to fit or result in a restructuring of all the data and procedures.
Object-Oriented Databases
Objected oriented databases address the problems of the domain model by encapsulating behavior and state into a single object. Provided that the objects implement an appropriate application program interface (API), it is possible to have collections of heterogeneous data. Further, new structures may be added to the database without requiring a major code rewrite. However, the drawback of object-oriented databases is that they are extremely difficult to access by external systems.
XML
XML, while not really a system, is widely used for the transfer of data between systems and has a growing following in the financial-risk management world. In XML, data is structured in a tree-like fashion, with named parts.
As a means to transfer data, XML has many advantages. For example, many APIs to other applications exist and it is flexible and extensible. However, XML does not offer any storage, update or query mechanism and the XML representation of objects is too verbose to be an option for storing data.